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(54) Remote device access over a network 

(57) The present invention provides a method for 
devices to be remotely accessed over a network. A 
renvyte device driver is cotpled to a txis device driver at 
a network client The remote dmce driver communi- 
cates to a renrxrte txjs proxy to a driver &ervk» in the 
server domain. Admce manager provkies responsftxl- 



rty for discovering servk^ on network cGents. enabling 
driver sconces to use the devices, rxslifying other driver 
services off the availatxlity of dmoes, notifying clinetsof 
the permissk)n to use a device by a service, and track* 
ing connected devk:es. 
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Description 

BACKGROUND OF THE INVENmON 
5 1. FIELD OF THE INVErOTION 

[0001 1 This irvention relates to the field of cxynputer systems. 

[0002] Portions of the disclosure of this patent document corttain material that is sttiject to copyright protection. 
The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent c£&- 
10 closure as it appears in the Patent and Trademark Office fie or records, but otherwise reserves all copyright rights wfiat- 
so^er. Sun, Sun Microsystems, the Sun logo, Java. JavaBeans. Holiava and all Java-based trademarks and k)gos are 
trademarks or registered trademark of Sun Microsystems, Inc. in ttie United States and other countries. 

2. BACKGROUND ART 

15 

[0003] Computer systems often include additk>nal devk:es used to provide additional functionality. These devk;es, 
often called "PftTphwar Ha^^^e^ include keytx>ards. printers, scanners, network irrterface arxl graphics cards, 
modems, monitors, cameras, and soind input devk:es. Generally, a device driver is used to corrtrol tfie periph_ec al 
device. In some network environments, the traditiorial device driver may not operate correctiy. This problem can be 

20 urKjerstood by a review of peripheral devices. 

[0004] Peripheral devces are often connected to a conrputer system through an expansion bus. An expansion bus 
allows the processor of a computer system (via software running on the processor), main memory, and other hardware 
associated with a computer system to control peripheral hardware devk^es external to the corrputer system An expan- 
sion bus consists of conductors for data and control signals, along with hardware support kygic chips and possibly 

25 firmware. There are a variety of eiq^ansion buses such as ISA (Industry Standard Architecture), PCI (Peripheral Com- 
ponent Interconnect). S-Bus, VME bus. etc. Each expanskxi bus defines a certain protocol by whk:h devces tfiat are 
on the bus are accessed. 

[0005] A deyk:e driver is s oftware used to control a peripheral device tfiat is coupled with the computer system on 
the bus. A dedc^drtwi ih n fllliumhl Ilii itoon trrTlTi n pnrlaculnr typn of devk^e that is attached to your o onixjter. There 

30 are devce drivers for printers, displays, CD-ROM readers, (fiskette drives, and so on. Many devk:e drivSsSre built into 
an operating system. New device drivers are needed for devk^es for whk:h the operating system does not already have 
drivers. A devk^e driver converts tt>e more ger>eral input/output instructions of the operating system to messages tfiat 
tf)e derice type can inderstand. In many corrputer system. devk:e drivers exist as a dynarnc link lixary (DLL) fie. 
[0006] Rgure 1 Blustrates symbolcally the interrelation of devtoes, devk:e drivers, and appik»Hon programs. 

35 Devces, such as devk^es A and B. oommunk»te throu^ a bus (such as an expansfon bus) to system software. The 
system software includes d^ce drivers (devk:e driver A and device driver B, respectively) irrplemented in the system 
software kernel. Applk:atiorts can access Ihe devices through the system software kernel and the appropriate devk^e 
drivers. 

[0007] A problem can arise where, in some network environments, a peripheral devk;e may not be coupled directly 
40 to the computer system through the bus, but rather through a network connectfon, via a so called H^in" or 'ultra-^hin" 
dient . For example, in an environment with a thin or uttra-thtn dient, it may not be possfole to errbed devk;e-specifk: 
code, such as devrce drivers, for tf>e large number of d^ces available. 

SUMMARY OF THE INVEf^ON 

45 

[0008] The present inverrtion provkles a method for devk»s to be remotely accessed over a network. A remote 
6&nce driver is coupled to a bus device driver at a network dient The remote devk:e driver communk^ates to a remote 
bus proxy to a driver sennce in the sewer domain. A devfoe manager presides responsibility for discovering services on 
network dients. enabling driver servfoes to use thedevces, notifying other driver servk;es of ttie availability of devfoes. 
50 notifying cGnets of ttie permission to use a devk:e by a servk;e. and tracking connected devices. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0009] 

55 

Figure 1 illustrates the relationship of deuces, device drivers, and applcation programs. 
Figure 2 illustrates an embodiment of the present inventioa 
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Figure 3 illustrates the virtual desktop environment of the present invention. 
Figure 4 is a bkx:k diagram of one errtediment of an HID of the present invention. 
5 Figure 5 illustrates a single chp HID embodiment of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

[001 0] The invention is a method and apparatus for accessing remote devices. In the following description, numer- 
10 ous specific details are set forth to provide a mae thorough description of embodiments of the invention. It wOl be 
apparent however, to one skilled in the art that the invention may be practiced wittxxit these specific details. In other 
instances, wefl known features have not been described in detail so as riot to obscure the invention. 

Virtual PesMop System Architecture 

IS 

[001 1 ] One environment in whk:h the present inventfon may be applied is in a virtual desktop system. One example 
of such a computer system is described in U.S. Patent Application nurTt>er 09^063,335 fled April 20. 1938 and entitled 
"Method and Apparatus for Providing a Virtual Desktop System Architecture". In such a system. tt>eir is provided a cen- 
tral office metapha to computing, where features arvl functkxis are provided by one or more sewers arxJ oommunk»ted 

20 to an appliance terminal through a network. Data providers are defir^ed as "sendees' and are provided by or>e or more 
processing resoi^ces. The services communicate to (fisplay terminals through a network, such as Ethernet The tenn- 
nals are configured to display data, and to send keyboard, cursor, audio, and vkieo data through the network to the 
processing sen/er. Functkxiaity is partitioned so that databases, sewer and graphical user interlace functfons are pro- 
vkied by the servces. and human interface functionaity is provkied by the terminal. Communk»tfon with the terminals 

25 from varfous servk^es is accomplished by converting (fisparate output to a common protocol. Appropriate drivers, are 
provided for each service to alkaw protocol conversfon. Multple terminals are coi^^led to the network. Users can enable 
their unic^e session at any one of the termirttis t)y togging in such as k>y insertir^g a "smart card" into a card reader. 
Removing the card disables the sesskxi. Re-inserting the card utto the same or any other terminal re-enatsles the ses- 
sfon. 

30 [0012] In the computer system described above, the interfaces for peripheral devk:es coupled to the hunan inter- 
face terrninal appear over a networtt protocol and do not involve operating system devk^ sertse. 
[0013] In this system the functfonality of the system is partitioned between a display and input derice. and data 
sources or servces. The display and irput devwe is a human interface devce (HID). The partitfoning of this system is 
such that stme arid corrputationfurKtioris have been removed from the HID arviresktoo^ In 

35 one embodiment of the invention, one or more services oommunkate with one or more HIDs through some intercon- 
nect fabric, such as a network. An example of such a system is ilktstrated in Figure 3. Referring to Figure 3. the system 
consists of computational service provklers 300 communk:ating data through interconnect fabric 301 to HIDs 302. 

Compiftatipnal Service Providers 

40 

[0014] In the HID system, the computational power and state maintenance is found in the servk;e provfoers. or 
services. The servk:es are not tied to a specifk; computer, but may be distributed over one or more traditional desktop 
systems such as desaik>ed in coruiectfon with Rgure 1 ; or witii traditional servers. One computer may have or>e or more 
services, or a service may be implemented t>y one or more corrputers. The service provkjes computation, state, and 

45 data to the HIDs arxi the servwe is under the control of a common authority or manager. In Rgure 3, the sendees are 
found on computers 310.31 1 ,312.313, and 314. It is important to note that the central data source can also be provtiing 
data that comes from outskle of the central data source, such as for example, the internet or worid wide webi The data 
source couU also be broadcast entities such as those that broadcast data such as televisfon or radfo signals. 
[001 SI Examples of servk:es include X1 1 AJnix services, archived or live audio or vkteo servfoes, Windows NT serv- 

50 ice. Java™ program execution servfoe, and others. A servfoe herein is a process that provides output data and responds 
to user requests and input. 

[0016] It is the responsfoility of the servfoe to handle communk:ations with the HID that is cunentiy being used to 
access the given servk:e. This irMslves taking the output from the corrputationalservk;^ 

protocol for the HID. This data protocol conversfon is handled in one embodiment of the invention by a mkfcleware layer, 
55 such as the X1 1 server, the Mk:rosoft Windows interface, a vkJeo format transooder, the OpenGL interface, or a variant 
of the java.awtgraphk:s dass) within the servk:e producer macNne. The servfoe machine handles the translation to and 
from the virtual desktop architecture wire protocol. 

[001 7] In an entxxiiment of the invention, each servfoe is provkjed by a computing devk^e optimized for its peribrm- 
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anca For exampld. an Enterprise dass machine oouU be used to provide X1 1 /Unix service, a Sun MediaCenter could 
be used to preside video service, a Hydra based ^^^ machine could provide applet prog'am execution service. 
[0018] The service producing computer systenrs connect directty to the HIDs through the interconnect fakxic. It is 
also possible for the service prockx^er to be a proxy for artOthef de^ce providing the conrputationa] service, such as a 
5 datat)ase computer in a three tiered architecture, where the proxy computer might only generate emeries and execute 
user interlace code. 

Mygonnytion Fatyig 

10 [001 9] In the inv^ention, the interconnection fabric is any of muttple suitable communication paths for carrying data 
t>etween the services and the HIDs. In one embodiment the ntercorviect fabric is a local area network implemented as 
an Ethernet network. Any other local network may also be utiized. The invention also contenrplates the use of wide 
area networks, the internet, the world wide web, and ottiers. The interconnect fatxic may be inplen)ented with a phys- 
ical HDedium such as a wire or f ber optic cable, or it may t>e irTplenr>ented in a wireless environment 

15 [0020] In one embodiment of the invention, the interconnect fabric provides actively mariaged. low-latency, high- 
bandwidth communications between the HID and the services t>etng accessed. One embodimerrt contemplates a sin- 
gle-level, switched netmrK with cooperative (as opposed to competing) network traffic. Dedicated or shared commu- 
nications interconnects may t>e used in the present invention. 

20 Human Interface Devices 

[0021] The HID is the mearis by whkih users access the conputational services provided t>y the servfo Figures 
illustrates HIDs 321,322. and 323. A HID ponststs of a display 326, a keyboard 324. mouse 325, and audfo speakers 
327. The HID includes the electronics need to interface these devfoes to the interconnection fatxfo arvJ to transmit to 

25 and receive data from the services. 

[0022] A ttock diagram of the HID is illustrated in Figure 4. The components of \he HID are cotpled ffiternally to a 
PCI tHJS 412. A network control bfock 402 comnunicates to the interconnect fatxic, such as an ethernet, through One 
414. An audfo codec 403 receives audfo data on interface 416 and is coupled to bfock 402. USB data communfoation 
is provided on lines 413 to USB controller 401. 

30 [0023] An embedded processor 404 may be, for example, a Sparc2ep with cotpled flash memory 405 and DRAM 
406. The USB controller 401 , network controller 402 and embedded processor 404 are all coupled to the PCI bus 412. 
Also cotpled to the PCI 41 2 is the video corttroller 409. The vkJeo controller 409 may k>e lor example, and ATI Ragel 28 
frame buffer controller (or any other suitable controller) that provides SVGA output on line 415. NTSC or PAL data is 
presided into video controller through vfoeo decoder 410. A smartcard interface 408 may also be cotpled to the video 

35 controller 409. 

[0024] Alternatively, the HID can be implemented using a single chip solution as illustrated in Figure 5. The single 
chip solution includes the necessary processing c^sabflity inplemented via CPU 501 and graphics Tenderer 505. Chip 
memory 507 is provided, afor)g with vfoeo controller/interface 506. A universal serial bus (USB) controller 502 is pro- 
vided to permit conrYnuntcation to a mouse, keyboard and other focal devfoes atfached to the HID. A sound controller 
40 503 and interconnect interface 504 are also provfoed. The video interface shares memory 507 with the CPU 501 and 
graphfos renderer 505. The software used in this enrfoodinient may resfoe locally in non vofatile memory or it can be 
loaded through the interconnection interface when the device is powered. 

Device Manager 

45 

[0025] The device manager is resportsftsle for kyokering devfoes that are attached to desktop units (HIDs) on the 
interconr>ection fat)ric tor tf>e purpose of remotely accessing the devices from various services. Since a desktop unit 
has no krxiwledge of most kirvte of dmces. it is not possfole for it to understand the semantics of the devfoe, and as a 
result, it is unable to directly control the device. 

so [0026] Thm means that device drivers should be provided bv services running elsewhere on the interco nnect. 
Th^fi Lfiennces locate devfoes to be controlled throuj^h the device manaaer. and then thev can directfy cont rol tha 
devfoe through the desktop unit The dmce services are treated as the servfoes described above in connection with 
the HID environment, so aitemion shoufo be pakJ to connection with the desktop unit session movement, and possible 
disconnection of the unit from tf>e interconnect. Finafly. since current peripheral bus architectures, such as USB, IEEE- 

55 1 394, and PC bus sipport hot-pluggir)g, both services and the device manager should be aware tfiat devfoes could be 
connected, disconnected, or nxsved whSe the desktop unit is functioning and wtule being controlled by a service. 
[0027] The device manager is also responsible for approving of servfoes, keeping an inventory of devices and their 
controlling servfoes. and focating devices on the interconnect Differed managenDent scenarios are made available 
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indidtng a ^obal device driver service (such as a Solaris™ nexus driver), a per-device driver, or a per-dass driver. 
There are also drfferertt scopes provided, such as interconnect scope, desktop scope, arvJ session soopa 
[0028] SiTKe the device nrianagementfranrimork is focused on controU it does not perfonm desktop unit 

location services, or service and user authentication. These functions are performed by the session manager arid the 

5 authentication nrianager respectively descril)ed in co-pending patent appfication serial nurrtw , 

entitted L_and tied on , and pjatent application serial 

nurTt>er , entitled M^hod and Apparatus for Remotely Administered Authentication and Access 

Control Services, filed on April 9,1999, and both assigried to the assignee of the present application. Device drivers in 
this context are services that join a session in the way described in the ovpendtng appfications, find their devices using 

10 the device manager and deal with the device d rectly using a protocol with the desktop unit. 

[0029] D^icernariagernerncorTtrolsaccessiMlityof devices to services, thus to users and user p^^ It is flex- 
ible erKXigh to handle a wide variety of sesskxi and service scenarios from individual devices to all of the devices 
addressed by the desktop unit. This is done by first establishing a connection with tfie desktop unit using the standard 
session management services. 

IS 

Block Diapram 

[0030] Figure 2 gives a tkxk c£agram o the cverall remote desktop architecture with device mar)agen>erTt included. 
Conponents irKlude servk:es 205, the sesskxi manager 204, the autherrtication manager 203, the authentk:atx>n han- 
20 dier 209 on the desktop side and the bus device driver 208. Also included are the remote device proxy 206, the devwe 
manager 201 , the remote device driver 207, and devices 210A - 210D coupled to bus 21 1 . 

[0031 ] The session manager 204 krxTws which services are associated with a partk:utar session and manages con- 
nectkxis with the desktop with the help of the autherrtication manager 203. The authentication manager 203 knows 
wtuch user is requesting access and wtuch session to associate with ttiat user. 

25 [0032] The device manager 201 uses the association between the user, session arxl desktop to map device serv- 
ices 205 to peulicular devices connected to particular desktop units. In tf^e process of doing this, the device manager 
201 can check a polk:y list 202 to oonpare what the servce is asking for and the user (sesskxi) with an adm in isti a tive 
poficy for device access permissioa If appropriate, then the device manager 201 registers the driver servk^e with the 
renrxTte device driver 207, and starts passing devk^e discovery oonfigu-abon events to the service. 

30 [0033] Sirx^e the device manager 201 controls the servk^e with respect to devrce attachment, the devk^e manager 
201 can inform the servk^e of device toss when a sesskxi ends, and, to enforce this, can inform the desktop unit that no 
more control of a partxxjlar device is permitted by a particular servk:a If the servce is controlling more than one device, 
ttien it may still be capable of controlling the other devrces. 

[0034] In one ennbodiment there is a k)gicafiy single devKe manager 201 much like there is a single sesskxi man- 
as agar 204 and authentication manager 203 per interconnect domain. This means that there are single connections 
between ttiedevce manager 201 and each of the sesskxi manager 204 and the authentication manager 203 the driver 
service connects to the session manager 204 as woiid any servx:e. It may be possible to phjnii the deince manager 
201 between the sesskxi manager 204 and driver servk^s to add the d^k:e management functionality to sesskxi serv- 
k;es. 

40 [0035] The renmte device drwer 207 is a standard devk:e driver hosted by ttie txis device driver 208. The remote 
device driver 207, however, emulates a number of devk:e clivers for tfie purposes of remote access, so it is likely to own 
all but a few of the deuces 21 OA - 21 OD on the desktop unit. As a resuh. the remote device driver 207 is responsit)le for 
keeping track of whk:h remote device servk;es 205 go to whk^h devces tfiat are exposed at the bus devk;e driver 208. 
Additionally, the remote devtoe driver 207 picks up configuration events from the bus devk» c^er 208 and reports them 

45 to tfie devk:e manager 201 for possft)le connection to a driver service. 

[0036] Rnally, tfie remote dwice driver 207 has the ability to permit and deny dB^ice and unit access by driver serv- 
ices. It maintains filters (gven to it by tfie device manager 201) of interested servk:es ttiat are directiy connected to it as 
well as a generic f Qter to report devices tfiat might not be session-specifk:. 

[0037] The authentication manager 203 maintains (posstofy interrrittent) connectkxis with each of tfie desktop 
so units for the purposes of authenticating users. This connection is used to additionally pass configuration information to 
and from the remote devce driver 207. This connection is not required to t>e fiil-time because it is only needed when a 
session doses dcwn (arxi tfien when a sesskxi-based poicy is in effect), and when configuration events occur for 
devices which do not currently fiave a service controlling them. 

[0038] The connection t>etween tfie remote device driver 207 and the driver service is fcx comnrtink:ating directiy 
55 with the device and reporting errors, de^ disconnectioa or k>ss of permisskxi. This connection can be intermittent 
because the connection may be bst wfien a sesskxi cfianges or when a device is no kxiger avaBat3le. 
[0039] The bus type determi nes th e protocol t)etween tfie sennce (tfie bus proxy 206) and the remote devk» driver 
207. The renxte devk:e driver's architectu'e and interface to the bus driver is also determined by tfie bus driver. Rnafly, 
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the device description format parts of the device ownership policy, and address space are also controlled by the bus 
type. 

[0040] ft is assumed that it is possible to track a user's authentication record from a session so it is possible to pro- 
vide access to devices and units based on user identity, ft is aiso assumed that it is possble to derive the desktop unit 
5 interconnect adctess from a session to enable communication with the desktop unit, to provide access to devices based 
on the identity of the desktop unit, and to track device assets based on desktop unit 

Device manaoer 201 

10 [0041 1 The Device manager 20 1 is responsUe for tuckering devices to services. In doing this, ft needs to intercede 
t>etween the remote device driver 207 and the driver service. The following is a step-by-step procedure for permitting a 
driver service to access a remote device: 

1 . When a device request (register) is received from the driver servk:e. ft is compared to the device access policy 
15 by conrparing each f ieki of the request to the polk:y. ft there is a field that is specified in the policy (e.g. has a specific 

value and is not wild-carded), axid the field does ncA match the field in the request, then the request is rejected. 
Incomplete matches are enabled tor the dass. model, and serial number, 

2. The attached device data is scanned for a match with the device request. Device requests match devices for the 
20 purpose of reporting back to the driver service. K there is an attached device ttiat matches, then a devk:e status 

(oonr>ect) message is sent to the driver service. Othenwise, no response is generated at this time. 

3. A received device request (register) is stored in the list of re^stered services. 

2s 4. ft a driver services wishes to be the configuration master of the devk;e. ft requests corrf 

wfth a devk:e request (configure) message, ft there is no current configuration servk^e, then the attached devk:e 
data is tpdated snd a driver regstration (configure) message is sent to the desktop mil Otherwise, the request is 
rejected. 

30 5. ft ttie driver service wishes to use a particular devce unft, then a device request (alk>cate) is received from ttie 
service which signifies tine server connection nunber (ag. Server socket) to be used for unft connection to this 
driver servk;e. Otfierwise, the dmce (or unft) remair^ available lor other servk:es to alkx»te. 

6. When a unft is allocated, then a driver registration (allocate) message is sent to the desktop unit 

35 

I, When a Devk^e dscovery message is received, then the devce is added or removed from attached devk:e data. 

8. When a device is added to ttie devce data, the selection data is rescanned lor a match, and device status (con- 
nect) messages may t>e generated if there are matches. 

40 

9. Receiving a device request (alkx^ate) renews the lease on a device unft. 

10. When a devk^e is removed from the device data, the selection data is re-scanned for matching servk;es. If a 
servk:e*s selection lifetime is met. ttien tt>e servk:e's registered selection is removed. 

45 

I I . When ttie connection wfth the driver servk:e is k>st. or a devk^e request (unregister) is received, or the selection 
IHetime criterion is met ttien the servk^'s registered selection is renxyved. 

12. ft a re^stered selection is removed, then a driver registration (remcNe) message is sent to the desktop unit 

50 

13. When ttie connection to the desktop unft is tost the devk^es connected to ttiat unft are removed from the list. 
Any interested sennces may have their registered selections remcwed if the selection lifetime is met. 

14. K a servx^e's lease on a devk» expires or a sesskxi lease expires, ttien a Driver Registration (remove) message 
55 is sent to ttie desMop unft. 
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IUU42] The desnce access pdicy is an external fite or database that 18 con^ 
rrdne if a request is vaTid. H contains the following fields: 

5 

a. user (session). 

b. server (e.g. tP address). 

10 c. deoce selection information: 

i. class (or none). 

ii. verxkx (or none), 
ill model (or none). 

75 iv. serial rumber (or nor>e). 

d. selection scope (session desktop unit, interconnect global), 

e. selection lifetime (session connected, device disconnect, permanent). 

20 

f. connection lifetime (session connected, session delayed, d^ce lease), 

g. maximum lease duration (in case session delayed or deince lease is enabled). 

2S [0043] Any Gtf the fields can be left blanK meaning any value in the request wai match that field. In order for a com- 
plete match, all specified fields should be matcfied. 

[0044] Class, model, and serial number allow incomplete matching if the amount specified in the policy matches the 
first part of the request strir>g. 

Unions are allowed for lifetime values (e.g. session connected or pennanent). 

30 

Device Access Request 

[0045] The 6wKe access request is used by driver services to register arxl unregister d&nce searches and set the 
communication capabiOties with the desktop unit. The server address and the session number are derived from the ses- 
35 skxi manager 204 connection. This request has several forms: (parenthesized expressfons are examples from the USB 
configuratfon specification). 

a. register: 

40 i. dass. 

ii. verxkx, 

iii. model. 

rv. serial number, 
V selectfon scope. 
45 vi. selectfon lifetin>e. 

vii. connection lifetime, 
vii. lease duratfon. 

b. configure: 

50 

I desktop unit address. 

ii. de^ address. 

iii. servfoe socket 

55 c. alfocate: 

i. desl^ unit address. 

ii. devfoe address. 
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Hi. unrt address, 
iv. service socket 

d. release 

5 

i. class, 

ii. vendor, 

iii. model, 

iv. serial number, 
10 V. selection scope. 

vi. selection lifetime, 

vii. connection lifetime. 

Deyice Digcqvery 

IS 

[0046] OeAce discovery is used by the desktop unit to report when devices change state - connected, discon- 
nected, owned, released. The desktop unit interconnect address is derived from the authentication manager 203 con- 
nection. This request has several forms: 

20 a. connect (sent on cormection. ownership or release): 

i. bus type (ag. USB. IEEE-1394), 
Ii. device address, 

iii. device dass (bOevicedass+bDeviceSubClas&fbDeviceProtoool. 
25 ModuIe_Spec_ld_+Module_SW_VerBion). 

iv. vendor (idVendor. Module_Vendor_ld). 

V. model friProduct+bcDevk». Module„HW_Version), 

vi. serial rujmber (iSerialNumber. Module_Unique_ld). 

vii. configuring server address. 

30 viii. configuring server socket number, 

ix. Units (Interfaces in USB): dass, controlling server address, controlling server socket number. 

b disconr>ect: 

35 i. bus type. 

ii. device address. 

PrW9$$ing 
40 [0047] 

1 . Tracks tf>e connection and disconr>ection of dances for aU desktop units on an interconnect 

2. Keeps a list of all devices currently attached devices on all functioning desktop units on an interconnect. This list 
45 includes (example mappings: USB, lEC/IS0 13213 [e.g. IEEE-1394]): 

a. Desktop unit intercorviect address, 

b bus type (ag. USB. IEEE-1394). 

50 

c. devk;e address, 

d. device dass (bDeviceClass+bDevk:eSubaas&k)Device Protocol. ModLie_Spec.ld+Module.SW_Versk)n). 
55 e. vendor (id VerxJor, Module.VerxJor.ld). 

t model OdProduct4bcdDevice, Modiie.HW.Version). 



8 



EP1043 876A2 

g. serial nurrber (tSerialNunnber. Module.Ltnique_ld). 

h. configuring service. 

I. configuring service socket nurrber, 
I Units (Inteffaces in USB): 

i. class (blnteffaceClass+*)lntertaceSubaa664blnteftaceProtocol. Unit_Spec_ld+Unit_SW_Version), 

ii. controlling service, 

iii. oontrolling service socket nurrber. 

3. keeps a list of all driver services registering interest in devices: 

a. user (Autherrtication manager 203 record, session). 

b. server (e.g. IP address). 

c. other identification irrfDrmation (e.g. process ID. progranrt name provided by tfie service). 

d. dmce selection request: 

i. class (or none). 

ii. vendor (or none), 

iii. model (or none), 

iv. serial number (or none), 

e. selectkKi scope (session desktop unit, interconnect gksbaQ, 

f. selectkxi lifetime (session conr>ected, device disconnect permanent), 

g. connectk)n lifetime {session connected, session delayed, device tease), 

h. lease duration. 

4. tnforrns driver services when a carididate device t>eoornes available wfiet^ 
(all approved services can read a devk;e*8 configuration space). 

5. Accepts dance access requests from services. Operational dance access requests apply only to individual units 
so nruttple services can control a single device. 

6. Controls dwice access permtsskx^ 

7. Conpares the dance access request to the device access policy. 

8. After authorization, registers a driver with a desktop unit 

9. In case of failure. a9 interested servk:es are recorstructed and each desktop unit queried on a tinf)e^avaitat)le 
basis for its current Sst of devk;es and owning servk:es. External programs can snapshot the dance manager 201 
state e.g. for invertory purposes, but that is not conskiered core or critkial device manager 201 functionality. Dance 
manager 20 1 failure does imply the temporary loss of the ability to connect some services to some devices. 

10. Driver services may register before the partKular device requested is available (e.g. in use or disconnected). 
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1. Device Status 

5 [0048] The device status message rs sent to the driver service when a device is connected or ownership changes. 
Disconnect events come directly from the desktop unit The message includes the data: 

a. Desktop unit interconnect address. 

10 b. bus type (e.g. USB. IEEE-1 1394), 

c. device address. 

d. device dass (bDeviceClas&4bDeviceSubClas&+bDeviceProtocol. Modu)e_Spec_kl4A/lodute_SW_Verskxi), 

75 

e. vendor (IdVendor, Module_Vendor_kO. 

f. model fidProduct-fbdcDevice. Module_HW_Vefsk)n). 
20 g. seriaJ number (iSerialNumber, Module_Unique_ld). 

h. configuration available, not avaBaUe. owned. 

i. Units (Interlaces in USB): 

25 

i. class. 

ii. control available, not available, owned. 
2. Driver Registratwn 

30 

[0049] The driver registration message is sem to the desktop unit to attempt to allocate a devi^ 
ice. There are three fams to this message: 

a. configure - sets configuration corrtrol to a particular service. 

3S 

bi uTKXXifigure - removes configuration control from a particular service, 
c. alkx:ate - sets unit control to a particular service. 
40 d. remove - removes unit control from a particular service. 
[0050] An three have the same arguments: 

a. bus type. 

45 

b. device address. 

c. unit address (zero for configure and tmconfigure). 
50 d. server address, 

e. server socket number. 
Driver Service 

55 

[0051 ] The driver service is the dient to devk:e management and aeated by an external party. 

[0052] The driver service needs to completely control the device; e.g.. Implement a complete device driver. As 

such. H is the responsisle party for creating devk:e requests. The driver service uses the remote bus proxy 206 to help 



10 



EP1043a76A2 



structire itseff with respect to a session and handfing the device protocol. 

[0053] After descnbing a controtlable device to the device manager 201 . the driver service waits for device status 
messages for the purpose of collecting the desktop unit address and the device number. When the device status mes- 
sage is received, then the driver service is free to read the device's configuration space using the remote txis proxy 206. 
5 tf the device is found to t>e inappropriate, the driver service warts for more device status messages, and opfonaily 
doses the socket it used to access the desktop unit tf the connection is still open and the device is unplugged, then the 
driver service receives remote device data tfiat r^lects this. 

[0054] If the driver service wishes to fully access the devk;e. it shouM first determine rf there is a current configura- 
tion. If there is, then it simply can start sending device rec^ests to open units. If tt>ere is not a current configuration, tt)en 
10 the service needs to t>ecome the configuration owner first. If the cfriver service is the conf iguratk>n owner, then it should 
set the configuration if \he bus and/or device require tfiat to t>e done. 

[0055] tf there are already open device units, tfien it is posst)le that the original configuration owner has given tp 

control of the conf iguratkxi. but the configuration cannot change until all of the units are dosed. 

[0056] After a unit is opened, tf)en read and write operations can happen on any of the conduits associated with the 

IS unit; the driver is the sole owner of tfiat unit 

[0057] If a sessk>n state change Is detected, the device marager 201 assumes tfiat the driver service wiU foUow its 
policy and either continuing to service device status requests, and corrtrolling the devk;e. or drop tf>e devk;e and wait for 
the session to estat^lish itself with a r)ew desktop unit TTie device manager 201 additionally enforces this. 
[0058] When the driver servk^e is done with a device, it releases all of its units using a device request (release) com- 

20 mand. If it was the configuratkHi owner, then it shouM release its configuration using a similar command. If the lease 
expires on the device, the socket is dosed, or rf the devk^e is disconnected, then all of this happens automatk^ally at tfie 
desMop unit. 

Inputs 

25 

[0059] 

1 . Device Status. 

2. Bus-specifk: remote devk^e data. 

30 

Processing 
[0060] 

35 1. Devce-spectfc servKes register from within the context Of a sesskxi. even if that is a special administrative ses- 
sk>n. 

2. The driver service is responsUe for describing the devk^es it can drive. This can be more tfian one devk^e. 

40 3. It is acceptable for driver sennces to discovery a dmce and to probe its configuratk)n space without either 
becoming the configuratkxi owner or opening any units. 

Outputs 

45 [0061] 

1 . Device Requests. 

2. Bus-specific renvste devk^e data. 

50 Rempt9Bii$Prqxy206 

[0062] The remote bus proxy 206 is an easy-to-use interlace fcx both the devce manager 201 and the remote 
devk^e driver 207. The remote bus proocy 206 converts functk)n calls into protocol for both of these. 
[0063] Since the renxjte bus proxy 206 handles the remote devk:e driver 207. its interi^ces are necessarily bus- 
55 specif c. For an example of a renxrte device &wef 207, refer to the USB renxite proxy 206 interface bekTw. 
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USB Bus Binding 
Deyice Dtscwefv Fqmats 
[0064] 

1 . bus type: USB=Ox0001xxxx where 65536 USB buses are allowed. 

2. donee address: 1-127. 

3. donee dass (bDeinceOa8&4l)Oevk:eSubC(a884bDevk;eProtocoO: 24 brts. variable in 8-brt inaemerrts. 

4. vendor OdVendor): 16 bits. 

5. model (idProduct-fbcdDeviee): 32 bits, vanat)le in 16-bit inaemerrts. 

6. serial number UNICODE string, optional, may vary according to LOCALE. 

7. configuring service: IP address. 

8. configuring service socket number: 16 txts. 

9. Units (Interfaces in USB): 

a. dass (blnterfaceCtas&+blnterfaceSuk>Clas&+blnterfaceProtoooO: 24 bits, variable in 8-b(t increments. 

b. controlling service: IP address. 

c. controlling service socket number: 16 bits. 

Ryngte DgvipQ Protocol 

[0065] Because all of tfie data for a session is being multiplexed onto a single socket it is important to use a call- 
resporise protocd smlar to the bask: USB protocol. This keeps badgxessure 

nection because only one transaction at a time is aHowed on an endpoint The entire protocol is done in two phases. 
One to send data or commands and another to receive data or status. Only disconnect events are asynchronous (but 
you can have only onef). 

The well-krKMvn port ior USB transactions is 5498. 

#define UT_USB_PORT5498 

[0066] The first data sent is a 16-t>it magk; number followed by a 16-bft command. After tfiat all data trarsfer is 
done in an even number of 4-byte words. The length of tfie command is derived from the command and then rourxied 
up to make an even number. 

#define UT_USB_MAQIC0x5554/* UT V 



typedef struct ut_usb_and I 

uintl6_t magic 

uintl6_tcmd; 

uintl6.t val; 

uintS.t addr; 

uintS.t endp; 
I ut_cm<Lt; 



[0067] VeU is an arginnent for the partkxiar command, addr is the device address from 1 -1 28. and endp is the end- 
point (unit in Device Mar^gement partaise) number from 0-15. 

[0068] The IN command is used to request data from an enc%x>int. and for ttiat data to be returned to the servk». 
Val encoded the size of t^ytes of tt>e desired read, or the amount of the data returned. 

#define Lrr_USBJN0x0096 

[0069] The SIATUS command is used to return status for OUT commands, or error status for t>ad IN commands. 
Error codes are fcxjnd in the vat f ieU and are TBD. but are extended from the OHCI transfer error codes. There win be 
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special error codes to designate that the enc^point is inaccessable. and to designate that the device is inaccessable 
and^ disconnected if the enc^xxnt is zero. Special error codes will not confEct with operational error codes. 

#define UT_USB_STATUS0x004b 

[0070] The OUT conrvnarxi is used to write data directly to an erxlpoint The length of the transfer is encoded in the 
val field. The respor^ from the device is always with a status conrvnand 

#defhe Lrr_USB_OLrrox0087 

[0071] The SETUP conrvnand is for sending a control trar^er. The 8 bytes immedately following the header 
desabe the control command. Val encodes the length of the data following and should eicactly ec^ the value in bytes 
6 and 7 of the corrtrol command. If the command is a read (txnRequestType & TRANS_REAO), then val should be zero. 

#define UT_USB_SETUP0x00b4 

A.3 Remote Interface Proxy 206 

[0072] 



typedef struct u^ubus I 
char^sesocnv 
char ^target; 
nvSeasion nvscssion: 
intaessioncni; 
intnet; 

uL.C3iuLtcind; 
uint8_tbuQ2048] 
)ulLubu8.t; 

typedef struct ut.4npe | 

uL.ubus.t ^ubusp; 

tntdev; 

intendpt; 
) ultj>ipc_t; 

uLubus^t *ut.u^ Jnis(ciuir ^sessicHV duur ♦taiget int threaded); 
vend ut.u8b jdone(ul^ubus_t *ubu8p); 
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ut.4npe_t •ut_usb_open{ut.ubiis_t *ubu7^ int dcv, int endpt); 
voit ut_usb_do6e(ut_pipe_t •pipep); 

* int ut_cxmtn>Lread(ut_ubus_t •p^>ep, int flagst, int request int value, int index, Int length, 
uintS.t Mata); 

int ut_contn)Lwrite(ut_pipe_t •pq^ep, int flagsi, int request int value, int index, int length, 
,^ uintS.t *data); 

int ut.5end_bulk(ut_pipe.t *pipep, uint8_t *data, int len); 
int uLxeoeive_bulk(ut_pipe_t *pipep, uint8_t *data, int kn); 

,5 int uLiegisterJiubevent(ut_ubus_t *ubusp, 

void (*) (ut_ubus_t ^ibu^, void *arg, uintl6_t val), 
void 'arg); 

int ut_registerjnterrupt(ut jjipe.t *pipep, 
20 void (*) (ut-Pipe_t *p^>ep, void •aig, int len), 

void *arg, int size, void *ptr); 

ut-CmcLt •ut_u8b,.getevent(ut.ubus.t *ubuqp); 

[0073] It is responsWe for sending requests and data to the device manager 201 and to the remote device driver 
207. rt also provides call-back routines for connect and disconnect events, and any other asynchronous event that the 
bus protocol dictates (e.g.. USB interrijpts). 

30 

Inputs 
[0074] 

35 1. Device status, 

2. Bus-specific remote device data. 

Prpp^ng 

40 [0075] Device manager 201 function should not be requred to maintain cunent device connections. In case of 
device manager 201 failure, connecting shoUd be retried. When a new connection is estat>lished. device request data 
should be sent to the device manager 201 for datat>as6 rebuild. 

Output? 

45 

[0076] 

1. Bus-spedfic device semantics. 

2. Device Request 

50 3. Bus-spedfic remote device data. 

Remote device driver 207 

[0077] The remote device driver 207 maintains relationships between the device manager 201, the requesting 
55 services and the actual bus device driver 208. It can tap all configiration activity on the bus. Its two primary funrt 
are to map configi^ation information to and from the device space and to convert protocol to and from device data. 
When a device is plugged in. unplugged, or the ownership of a device changes, the remote device driver 207 should 
send a device disccvery message. 
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[00781 When a dance is unptugged or becomes inaccessible to a particUar service, then it should send an urptug 
message over the socket to the &uer service and disable that device connection for that service (alttxxjgh it should not 
removeallofthecttfviceconnectionsrf they are not ail iiivalid). If the coniiuction to the driver service is lost it should free 
all of the resources being held by ttiat service arxJ rxstify the device manager 201 . 

[0079] When the device manager 201 sends a driver registration m^sage. the remote device drive enables the 
designated port for the desisted resource, tf the designated resource is not available, the remote device driver 207 
sends a device cfisoovery message to tf)e device manager 201 reminding it who currerrtly owns that resource. If the 
resource is available, the resource is available, the resource is allocated and enataled. and a device dscovery message 
is serrt to the device manager 201 to irxiicate the new owner. 

[0080] The device manager 201 will, from time to time, send driver registration nr>essages incf eating that a service 
no longer has access to a device or unit. In this case, that resource is deallocated, a disconnect message is sent to the 
driver service, and a device discovery message is sent to the device manager 201 to incficate that the resource has 
been released. 

[0081 ] If the connection to the device manager 201 is lost then this is retried until connection is reestat)lished, then 
all of the currerrt device data is sent to the dance manager 201 using dance discovery messages. 

[0062] 

1. Bus-specific commands and data. 

2. Driver Registration. 

PrpcQS^ng 
[0083] 

1 . In order to realize one connection per service per desktop unit, it is necessary to perform flow control at the txfi 
level rather than at the connectkxi level. 

2. For accounting purposes, a remote devk:e driver 207 reports devices which it does not manage or are currently 
not connected to a service to the dwice manager 201 . 

3. It is possUe for the configuration space of all dances, including devices used internally to the desktop unit, to be 
queried, but if a device is in use (either locally or renrxDtely) it is not possUe to change the oonf iguratfon (other than 
to connect to a service in the case of an unused device) nor to transfer operatfonal data to or from these devices. 

4. If there are already open device units, then it is possUe that the original configuration owner has given ip control 
of the conf iguratfon. but the configuration cannot change until all of the units are closed. 

5. RenxTte device driver 207s should be atiie to derry connections to devices from services directly. This is impor- 
tant for policy enforcement. 

6. Device manager 201 function should not be required to maintain the list of current device connections. 

7. In case of device manager 201 failure, connecting should be retried. When a new connection is established, all 
device discovery data should be sent to the device manager 201 for database rebuild. 

8. Informs afl interested driver services when a devk^e is disconnected whether or not they have exerted any control 
over the devk:e. 

Outputs 
[0064] 

1. Bus spedfk: status and data. 

2. Device Discc^ery events. 
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Externa) Interface Reouiremente 
[00B5J 

5 1 . The Darice manager 201 uses the authentication manager 203 connection for a secure, and ut>iquitou8 connec- 

tion to aO desktop units. 

2. The 6wce manager 201 uses the session manager 204 connection to t>e sure that the session that is making 
requests is currentty attached to the desktop unit rt wants to control. 

3. The 69nce manager 201 does not authenticate individual users, ft is up to programming on the device manager 
10 201 target platform to provide a connectfon ffito the device manager 201 which can authorize individual users. 

Qpmnynic^tiQn lntyfa<;^ 

[0086] 

15 

1 . All remote interfaces use sequenced, reliable byte streams. 

2. AH communicatior^ interfaces depend on the installed networking infrastructure, which is not specified. InrtiaJ 
versions are for TCP/IP at all interfaces. 

20 

[0087] The features discfosed in the foregoing desaiptfon. in the dam arxlfor in the acconpanykig drawings may, 
both separately and in any oombinatfon thereof, be material for reelisir>g the inventfon in diverse forms thereof. 

Claims 

25 

1 . A devk:e manager for providing a device driver for a devfoe comprising: 

a devfoe servfoe for requesting a device: 
a remote bus proxy for communk:ating with a diertt device: 
30 a renrxite devfoe driver cotpled to a dient device: 

a devk:e manager for controlGng oommunk^atfons between said devk;e service and said remote devfoe driver. 

2. An apparatus for providirig access to one or more remote dances over a network, comprising: 

35 a remote devfoe driver coupled to OTYe or more dances: 

one or more driver servfoes configured to remotely control one or more of said devices, wherein sakf remote 
device cblver tracte wfik:h of said one or more driver services communicates with whk:h of said one or more 
devices: and 

a device manager configured to register one or more of saki d^ce sennces with sakl renxTte devfoe driver to 
40 access one or more of saki devfoes. 

3. The apparatus of claim 2, wherein said one or more driver sendees and saki device manager reside in a server 
domain coupled across a network to saki renrxTte devk^e driver. 

45 4. The apparatus of daim 2, further oorrprising: 

a bus device driver cotpting saki remote devk;e driver to saki one a more devces; and 
a txis proxy couplirig sakS one or more driver servk:es to sakJ renrxste device driver. 

50 5. The apparatus of daim 2. further comprising: 

a sesskxi manager oonfigued to associate one or more sesskxis with one or more of saki driver sennces:and 
an authenticatfon manager configured to associate one or more sessfons with one or rrvKe dients. 

55 6. The apparatus of daim 2. wherein saki device manager is configured to enforce a devce access polk:y for re^s- 
XBnng sakj one or more driver services. 

7. The apparatus of daim 2. wherein saki device manager maintains an Inventory of devk^es and respective control- 
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8. The apparatus of claim 2. wherein said device manager is configured to kx:ate said one or more device& 

5 9. The apparatus of claim 2, wherein said device manager is configured to notify a first driver service of loss of a first 
device when an associated session ends. 

1 0. The apparatus of daim 9. wherein said device manager is further configured to notify said renrxrte device driver ttiat 
said first driver service is no kxiger permitted to control said first device. 

10 

11. The apparatus of daim 2 wherein said remote device driver is configured to notify said device manager of a con- 
figuration change in said one or more devices. 

12. The apparatus of daim 2, wherein said remote device driver comprises a fitter for permitting and denying access 
IS by one or more of said driver services, said fitter provided by said device manager. 

13. A method for providing access to one or nxxe remote deoces ever a network, comprising: 

a device manager receiving a device request from a driver service: 
20 said device manager registering said driver service with a remote device driver; and 

said driver service comnunicating with a remote device via said remote device driver. 

14. The method of daim 13, further conrprising said remote device driver sending device configuration information to 
said device mariager. 

25 

15. ThemetfKxJofdaim 13. further conprising a bus dBrice driver exposing one or nxxe devices to sa^ 
driver. 

16. The method of daim 13. further comprisir^g: 

30 

associating a session with said driver service via a session nrtanager; and 
associating said session with a dient via an authentication manager. 

17. The method of daim 13, wherein registering said driver service comprises enforcv>g a device access policy. 

35 

18. The HDetfKXl of daim 13, further comprising maintaining in said remote device, drwer an association between one 
or more dences arxl one or more driver services. 

19. The method of daim 13. further comprising said device manager maintaining an inverrtory of devices and respec- 
40 tive controlling driver services. 

20. The metfiod of daim 1 3. further comprisff>g said remote device driver permitting arxJ denying access to one or nrvxe 
devices t>ased on a f tfter provided by said device manager. 

45 21. The metfKsd of daim 13, furtfier comprising said device nnanager locating one or more devices on said network. 

22. The method of daim 13. further comprising said device manager notifying said driver service of loss of said device. 

23. The method of daim 22. wherein said k>ss of said devk:e is in response to the dosir^g of an assodated session. 

50 

24. The method of daim 22. further comprising saki device manager notifying said remote device driver that said driver 
servk» is no tonger permitted to control said device. 

25. A conputer program product comprising: 

55 

a computer usable medium having computer readable pro-am code embodied tf>erein for caustrtg a computer 
to provide access to a remote dence across a network, said computer readable pro-am configured to cause 
said computer to perform the steps oh 
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receive a device request from a driver service; 

register said driver service with a rerrxste device driver; arxl 

enable said driver service to comrrunicate with a remote device via said remote device driver. 

26. The corrputer program product of daim 25. wherein said corrputer readable program code is further configured to 
cause said computer to receive device coitf iguration inlbrmation from said remote device driver. 

27. TTie computer program product of claim 25. wherein said computer readable program code Is further configured to 
cause said computer to; 

associate a session with said driver service via a session maruger; and 
associate said session with a cGent via an authentication manager. 

28. The computer program product of daim 25. wherein registering said driver service corrprises enforcing a device 
access policy. 

29. The corrputer program product of daim 25. wherein said computer readable program code is further configured to 
cause said corrputer to maintain an inventory of devices and respective controllir>g driver services. 

30. The computer program product of daim 25. wherein said corrputer readable program code is further configured to 
cause said computer to provide a fitter to said remote device driver for use in perrrvtting and denying access to one 
or more devices. 

31. The computer program produd of daim 25. wherein said corrputer readable program code is fulher configures to 
cause said corrputer to locate orre or more devices on said network. 

32. The corrputer program product of daim 25. wherein said corrputer readable program code is futher corrf igured to 
cause said conputer to notify said driver service of loss of said device. 

33. The computer program product of daim 32. wherein said loss of said device is m response to the dosing of an 
associated session. 

34. The corrputer program product of daim 32 wherein said corrputer readable program code is further corrf igiH-ed to 
cause said computer to notify said remote device driver tfiat said driver service is no longer permitted to oorrtrol 
said device. 
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APPUCATION 
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